<!-- HTML header for doxygen 1.8.5-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.17"/>
<title>GenAVB/TSN: Streaming API usage</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<script src="http://www.freescale.com/files/abstract/misc/COLLATERALTEMPLATE_infocenter.js" type="text/javascript" xml:space="preserve"><!-- --></script>
<link href="navtree.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="resize.js"></script>
<script type="text/javascript" src="navtreedata.js"></script>
<script type="text/javascript" src="navtree.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&amp;dn=gpl-2.0.txt GPL-v2 */
  $(document).ready(function() { init_search(); });
/* @license-end */
</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="html_custom.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr style="height: 56px;">
  <td id="projectlogo"><img alt="Logo" src="nxp_logo.png"/></td>
  <td style="padding-left: 0.5em;">
   <div id="projectname">GenAVB/TSN
   </div>
  </td>
   <td>        <div id="MSearchBox" class="MSearchBoxInactive">
        <span class="left">
          <img id="MSearchSelect" src="search/mag_sel.png"
               onmouseover="return searchBox.OnSearchSelectShow()"
               onmouseout="return searchBox.OnSearchSelectHide()"
               alt=""/>
          <input type="text" id="MSearchField" value="Search" accesskey="S"
               onfocus="searchBox.OnSearchFieldFocus(true)" 
               onblur="searchBox.OnSearchFieldFocus(false)" 
               onkeyup="searchBox.OnSearchFieldChange(event)"/>
          </span><span class="right">
            <a id="MSearchClose" href="javascript:searchBox.CloseResultsWindow()"><img id="MSearchCloseImg" border="0" src="search/close.png" alt=""/></a>
          </span>
        </div>
</td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.17 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&amp;dn=gpl-2.0.txt GPL-v2 */
var searchBox = new SearchBox("searchBox", "search",false,'Search');
/* @license-end */
</script>
</div><!-- top -->
<div id="side-nav" class="ui-resizable side-nav-resizable">
  <div id="nav-tree">
    <div id="nav-tree-contents">
      <div id="nav-sync" class="sync"></div>
    </div>
  </div>
  <div id="splitbar" style="-moz-user-select:none;" 
       class="ui-resizable-handle">
  </div>
</div>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&amp;dn=gpl-2.0.txt GPL-v2 */
$(document).ready(function(){initNavTree('streaming_usage.html',''); initResizable(); });
/* @license-end */
</script>
<div id="doc-content">
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div class="PageDoc"><div class="header">
  <div class="headertitle">
<div class="title">Streaming API usage </div>  </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><p>The streaming API makes it possible to create, destroy AVTP streams, and to send and receive data to/from those streams.</p>
<p>Although the AVTP protocol is inherently packet-oriented, the GenAVB stack hides the encapsulation/decapsulation work from the application, and instead exposes a stream-oriented API: the data is viewed as a continuous stream of bytes, in order to relieve the application from most of the low-level protocol details. Additional information, if present (lost data, end of frames for video streams, etc), is conveyed "out-of-band", as an array of <a class="el" href="group__stream.html#structgenavb__event">genavb_event</a> provided alongside the data bytestream.</p>
<p>Streams are created using the <a class="el" href="group__stream.html#ga1edca94485ef63e234a5012187255588" title="Create a new AVTP stream.">genavb_stream_create</a> function (see below). Following the AVTP logic, a stream represents a unidirectional flow of data between a Talker (the entity sending data over the AVB network) and a Listener (the entity receiving that data). When data is ready to be sent or received (see below <a class="el" href="streaming_usage.html#flow_control">Flow control</a>), the application may use <a class="el" href="group__stream.html#ga04dfd629347336da56741cbabf021bf5" title="Send media data on a given AVTP stream.">genavb_stream_send</a>, ::genavb_stream_send_iov, <a class="el" href="group__stream.html#ga3f6239c9a0914082dd5fd76f0507e5b4" title="Receive media data from a given avb stream.">genavb_stream_receive</a>, ::genavb_stream_receive_iov functions to send or receive data, depending on the stream direction. When a stream is no longer needed, it may be destroyed with the <a class="el" href="group__stream.html#ga8ad1f9febe073b91fadc3b3aca802398" title="Destroy a given AVTP stream.">genavb_stream_destroy</a> function.</p>
<h1><a class="anchor" id="stream_creation"></a>
Stream creation</h1>
<p>Creation of an AVTP stream on an endpoint can be done using the <a class="el" href="group__stream.html#ga1edca94485ef63e234a5012187255588" title="Create a new AVTP stream.">genavb_stream_create</a> function. This function must be provided with an <a class="el" href="group__stream.html#structgenavb__stream__params">genavb_stream_params</a> structure, which may be initialized in two different ways:</p><ul>
<li>Static mode</li>
<li>AVDECC mode</li>
</ul>
<h3><a class="anchor" id="autotoc_md0"></a>
Static mode</h3>
<p>The application must set all fields of <a class="el" href="group__stream.html#structgenavb__stream__params">genavb_stream_params</a> by itself. Some helpers macros are provided in the genavb header files to ease that process, in particular for the <a class="el" href="group__stream.html#aa67a91c8a43125d74296e5538c4b3eb1" title="Stream media format (in network order)">genavb_stream_params.format</a>.</p>
<h3><a class="anchor" id="autotoc_md1"></a>
AVDECC mode</h3>
<p>The :<a class="el" href="group__stream.html#structgenavb__stream__params">genavb_stream_params</a> structure is provided to the application by the AVDECC component of the GenAVB stack, using an <a class="el" href="group__control.html#gga55b3a83feba03f6cf5bcbc0d7e1438d1a39cbe0a54bff1c415102b053715ba479" title="Stream connect message (from GenAVB stack to media stack/application).">GENAVB_MSG_MEDIA_STACK_CONNECT</a> message sent to the application on a <a class="el" href="group__control.html#ggabe9c9a1e2ef8ec04e182c12131397b6ead4e4880c606c6f67e911197fc47d942e" title="Notification of stream connections/disconnections to the media stack.">GENAVB_CTRL_AVDECC_MEDIA_STACK</a> channel. The application can receive the message (which maps to the <a class="el" href="group__stream.html#structgenavb__stream__params">genavb_stream_params</a> structure) using the <a class="el" href="group__control.html#gaf98c2c44f87c3315ab02060426128f5b" title="Receive control message from the GenAVB stack.">genavb_control_receive</a> call. See <a class="el" href="control_usage.html">Control API usage</a> for details on how to receive such messages. Macros are also available to help extract information from the <a class="el" href="group__stream.html#aa67a91c8a43125d74296e5538c4b3eb1" title="Stream media format (in network order)">genavb_stream_params.format</a> field. When relying on AVDECC, an <a class="el" href="group__control.html#gga55b3a83feba03f6cf5bcbc0d7e1438d1a39cbe0a54bff1c415102b053715ba479" title="Stream connect message (from GenAVB stack to media stack/application).">GENAVB_MSG_MEDIA_STACK_CONNECT</a> message is triggered in several</p>
<p>situations:</p><ul>
<li>Fast-connect mode: this mode is described in section 8.2.2.1.1 of the IEEE 1722.1-2013 standard. A listener sends an <a class="el" href="group__control.html#gga23209314df1f8a256ff131c24c0e713fa13b2f0a45023e4247b288358d54b7751" title="Connect Talker Stream source command.">ACMP_CONNECT_TX_COMMAND</a> to a talker once it discovers a talker that matches the saved state on the listener. On the Linux platform, that saved state (entity id, stream unique id) can be provided to the GenAVB stack through run-time options.</li>
<li>Back-to-Back (BTB) mode: this is a non-standard variation of Fast-connect, where the listener tries to connect to the first talker discovered on the network. This mode is used in several GenAVB demos where it is known in advance the setup has only one talker advertising itself on the network.</li>
<li>Controller-connect mode: this mode is described in section 8.2.2.1.3 of the IEEE 1722.1-2013 spec. A controller initiates the stream connection by sending a <a class="el" href="group__control.html#gga23209314df1f8a256ff131c24c0e713fadf908dc603c9b60a3eb8777f83980122" title="Connect Listener Stream sink command.">ACMP_CONNECT_RX_COMMAND</a> to a listener, and receives a <a class="el" href="group__control.html#gga23209314df1f8a256ff131c24c0e713fae6d2f5f0fa74b3eca2a02a795fb14507" title="Connect Listener Stream sink response.">ACMP_CONNECT_RX_RESPONSE</a> from that listener once the stream has been successfully connected.</li>
</ul>
<p>Once a listener decides to connect a stream (based on one of the previous situations) the sequence of events remains the same in all cases, and is described by the solid black arrows in the following diagram.</p>
<div class="image">
<img src="acmp_connect.png" alt=""/>
<div class="caption">
ACMP controller-connect and fast-connect modes</div></div>
   <p>Diagram legend:</p><ul>
<li>Gray events are only present in controller-connect mode.</li>
<li>Black events are present in all modes (fast-connect, BTB, controller-connect).</li>
<li>single-line arrows: network packets.</li>
<li>dual-line arrows: messages/function calls between customer application and GenAVB stack.</li>
</ul>
<h1><a class="anchor" id="flow_control"></a>
Flow control</h1>
<p>A callback can be registered using <a class="el" href="group__stream.html#ga4005d566d3a9fbd49ee065827c3cfaa5" title="Sets a callback, used by GenAVB stack, to report stream related events.">genavb_stream_set_callback</a> which is called when received data is available or when buffer space is available for transmit. The callback must not block and should notify another task which performs the actual data reception/transmission. After the callback has been called it must be re-armed by calling <a class="el" href="group__stream.html#gae4457441f9e95631dac313dd5a123b8d" title="Enable stream callback.">genavb_stream_enable_callback</a>. This should be done after the application has read all data available/written all data available (and never from the callback itself). The amount of data that triggers a wake-up is configured through the batch_size argument of <a class="el" href="group__stream.html#ga1edca94485ef63e234a5012187255588" title="Create a new AVTP stream.">genavb_stream_create</a>. The GenAVB stack only processes data one AVTP packet at a time, so the configured batch size is always a multiple of the payload size of an AVTP packet for the given stream.</p>
<h1><a class="anchor" id="rx_data"></a>
Receiving data (listener stream)</h1>
<p>Reception of stream data can be done through <a class="el" href="group__stream.html#ga3f6239c9a0914082dd5fd76f0507e5b4" title="Receive media data from a given avb stream.">genavb_stream_receive</a> and ::genavb_stream_receive_iov. These functions behave the same, except for the way the data buffers are passed along:</p><ul>
<li><a class="el" href="group__stream.html#ga3f6239c9a0914082dd5fd76f0507e5b4" title="Receive media data from a given avb stream.">genavb_stream_receive</a> accepts a single pointer to the memory area where data should be copied, along with the buffer length,</li>
<li>::genavb_stream_receive_iov uses an array of <a class="el" href="group__stream.html#structgenavb__iovec">genavb_iovec</a>, making it possible to use a scatter-gather scheme and have data be copied directly into various memory buffers.</li>
</ul>
<p>Both functions are non-blocking, so they may return less data than requested if not enough is available.</p>
<p>If the event* arguments are set, events that may have occurred in the stream are returned as well. Common events may be timestamping information, end-of-frames, but also non-recurring events/errors, such as packet loss. To ease the processing on the application side, some events force "short reads", where the stack returns less data than requested even if more was available. When that happens, reading the last returned event provides an easy way for the application to determine what happened and take appropriate action.</p>
<p>Different stream formats behave in different ways, so some types of events may or may not be relevant in all cases. The following sections list the various events available for each stream format and their meaning.</p>
<h3><a class="anchor" id="autotoc_md2"></a>
Audio</h3>
<h4><a class="anchor" id="autotoc_md3"></a>
61883-6</h4>
<p>TBD</p>
<h4><a class="anchor" id="autotoc_md4"></a>
AAF</h4>
<p>TBD</p>
<h3><a class="anchor" id="autotoc_md5"></a>
Video</h3>
<h4><a class="anchor" id="autotoc_md6"></a>
61883-4</h4>
<ul>
<li>AVTP timestamps are normally present at the beginning of every MPEG Transport Packet (188 bytes), unless the <a class="el" href="group__stream.html#ga88c1c6af5065f0f5e009f83093df1a2a" title="AVTP timestamp invalid event, based on AVTP stream header tv bit.">AVTP_TIMESTAMP_INVALID</a> flag is set in the event mask.</li>
<li><a class="el" href="group__stream.html#gaabac3d782b8271940bda704fc61af46a" title="AVTP packet loss event, base on AVTP stream format sequence number.">AVTP_PACKET_LOST</a> is set when data was lost. The GenAVB stack considers data was lost when the AVTP sequence numbers of successive packets are not contiguous. This event forces a short read.</li>
</ul>
<p>Because the GenAVB stack only wakes up the application after at least batch_size bytes are available, an application that doesn't use a timeout with poll/epoll/select system calls may receive some data after its presentation time has expired, because the data remained in the GenAVB stack as part of a partial batch. This may for example happen:</p><ul>
<li>when reaching the end of a video,</li>
<li>with sparse streams consisting of long periods of silence between bursts of data It is therefore recommended to always set a timeout with poll/epoll/select, and when a timeout occurs, to read the pending data (whose amount will be less than batch_size). The timeout value can be determined based on the additional buffering that is done within the application to process the data: for example, with a Gstreamer pipeline that adds several hundreds of ms latency, a value of 100ms would be a reasonable value to make sure data is received in time without starving the Gstreamer pipeline, while also preventing the timeout from happening all the time (which would negate the advantages of using poll/epoll/select).</li>
</ul>
<h4><a class="anchor" id="autotoc_md7"></a>
CVF/MJPEG</h4>
<ul>
<li><a class="el" href="group__stream.html#gaabac3d782b8271940bda704fc61af46a" title="AVTP packet loss event, base on AVTP stream format sequence number.">AVTP_PACKET_LOST</a> is set when data was lost. This event forces a short read. The GenAVB stack considers data was lost in several situations:<ul>
<li>when the AVTP sequence numbers of successive packets are not contiguous,</li>
<li>when the fragment_offset fields of the MJPEG headers of successive packets show a discontinuity or an overlap.</li>
</ul>
</li>
<li><a class="el" href="group__stream.html#ga5b3fb974cb1ea2d99de92d85e786e938" title="End of frame event, based on AVTP CVF M bit.">AVTP_END_OF_FRAME</a> is set on the last byte of a video frame. This is determined by the GenAVB stack based on the M bit of the AVTP header. That event also forces a short read, to make it easier for the application to group together data for a single NALU.</li>
</ul>
<h4><a class="anchor" id="autotoc_md8"></a>
CVF/H264</h4>
<ul>
<li><a class="el" href="group__stream.html#gaabac3d782b8271940bda704fc61af46a" title="AVTP packet loss event, base on AVTP stream format sequence number.">AVTP_PACKET_LOST</a> is set when data was lost. This event forces a short read. The GenAVB stack considers data was lost when the AVTP sequence numbers of successive packets are not contiguous.</li>
<li><a class="el" href="group__stream.html#ga5b3fb974cb1ea2d99de92d85e786e938" title="End of frame event, based on AVTP CVF M bit.">AVTP_END_OF_FRAME</a> is set on the last byte of a NALU. This is determined by the GenAVB stack based on:<ul>
<li>The last FU-A packet.</li>
<li>A single NALU packet</li>
<li>The Marker bit.</li>
<li>The last NALU of a STAP packet. If a STAP packet contains several NALUs, only the last one will have an event. The application needs to do custom h264 parsing to get NALUs seperated. That event also forces a short read, to make it easier for the application to group together data for a single frame. For H264, the timestamps passed to the application layer correspond to H264 timestamps as defined in IEEE1722-2016 Section 8.5.3.1 (and not avtp timestamps) Thus, <a class="el" href="group__stream.html#ga88c1c6af5065f0f5e009f83093df1a2a" title="AVTP timestamp invalid event, based on AVTP stream header tv bit.">AVTP_TIMESTAMP_INVALID</a> is used to indicate the validity of the h264 timestamp.</li>
</ul>
</li>
</ul>
<h3><a class="anchor" id="autotoc_md9"></a>
Control</h3>
<h4><a class="anchor" id="autotoc_md10"></a>
ACF/NTSCF</h4>
<p>The following events can be propagated to the media interface:</p><ul>
<li><a class="el" href="group__stream.html#gaabac3d782b8271940bda704fc61af46a" title="AVTP packet loss event, base on AVTP stream format sequence number.">AVTP_PACKET_LOST</a> is set when data was lost.</li>
</ul>
<h4><a class="anchor" id="autotoc_md11"></a>
ACF/TSCF</h4>
<p>The following events can be propagated to the media interface:</p><ul>
<li><a class="el" href="group__stream.html#ga88c1c6af5065f0f5e009f83093df1a2a" title="AVTP timestamp invalid event, based on AVTP stream header tv bit.">AVTP_TIMESTAMP_INVALID</a>/<a class="el" href="group__stream.html#ga36b7375f8d60ce9b0886814010a9fa1a" title="AVTP timestamp uncertain event, based on AVTP stream header tu bit.">AVTP_TIMESTAMP_UNCERTAIN</a> are set to indicate the validity of the avtp timestamp</li>
<li><a class="el" href="group__stream.html#gaabac3d782b8271940bda704fc61af46a" title="AVTP packet loss event, base on AVTP stream format sequence number.">AVTP_PACKET_LOST</a> is set when data was lost</li>
</ul>
<p>Note: if none of the <a class="el" href="group__stream.html#ga88c1c6af5065f0f5e009f83093df1a2a" title="AVTP timestamp invalid event, based on AVTP stream header tv bit.">AVTP_TIMESTAMP_INVALID</a>/<a class="el" href="group__stream.html#ga36b7375f8d60ce9b0886814010a9fa1a" title="AVTP timestamp uncertain event, based on AVTP stream header tu bit.">AVTP_TIMESTAMP_UNCERTAIN</a>/<a class="el" href="group__stream.html#gaabac3d782b8271940bda704fc61af46a" title="AVTP packet loss event, base on AVTP stream format sequence number.">AVTP_PACKET_LOST</a> events are set, a valid timestamp can be read from the events array.</p>
<h1><a class="anchor" id="tx_data"></a>
Sending data (talker stream)</h1>
<p>Sending stream data can be done through <a class="el" href="group__stream.html#ga04dfd629347336da56741cbabf021bf5" title="Send media data on a given AVTP stream.">genavb_stream_send</a> and ::genavb_stream_send_iov. These functions behave the same as their receive counterparts, except they are used for sending data instead of receiving data.</p>
<p>Compared to the receive direction, another set of events is used to reflect the different requirements of the talker side.</p>
<h3><a class="anchor" id="autotoc_md12"></a>
Audio</h3>
<h4><a class="anchor" id="autotoc_md13"></a>
61883-6</h4>
<p>TBD</p>
<h4><a class="anchor" id="autotoc_md14"></a>
AAF</h4>
<p>TBD</p>
<h3><a class="anchor" id="autotoc_md15"></a>
Video</h3>
<h4><a class="anchor" id="autotoc_md16"></a>
61883-4</h4>
<p>AVB stream reservations (using SRP) usually result in fairly small packets being sent at a fairly high rate. For example, a 24Mbps Class A SRP reservation for a 61883-4 stream would be done by using a max AVTP payload size of 384 bytes (2 MPEG TS packets, (188+4)*2), and a rate of 8kpps. However, because a 61883-4 stream is usually VBR, the actual rate is most of the time lower. As a consequence, the GenAVB stack needs to have timing information for each packet in order to respect that variable rate (and to provide accurate timestamps inside the packets).</p>
<p>This packetization scheme results in the following constraints:</p><ul>
<li><a class="el" href="group__stream.html#ga31ffedf58931d498048116f43ba42cea" title="Synchronization event.">AVTP_SYNC</a> events with valid timestamps should be added to mark the beginning of every MPEG Transport Packet, to ensure the stack has the information it needs to send AVTP packets at an accurate time and with valid AVTP timestamps.</li>
<li><a class="el" href="group__stream.html#ga95b57551cb8d38631d7482b0cd7f7549" title="Flush event.">AVTP_FLUSH</a> events should be added as the first event when calling <a class="el" href="group__stream.html#ga04dfd629347336da56741cbabf021bf5" title="Send media data on a given AVTP stream.">genavb_stream_send</a>/::genavb_stream_send_iov, if the associated data should be sent immediately even if it results in a partial packet being sent. This is useful for example:<ul>
<li>when reaching the end of a video, to ensure data for the last frame is sent without delay,</li>
<li>or with sparse streams when the amount of data is often small and the bitrate very irregular (such as when sending display updates for a remote GUI)</li>
</ul>
</li>
</ul>
<blockquote class="doxtable">
<p>Note: because of current GenAVB API limitations, an application cannot set the rate to use with a given stream, and as a result all 61883-4 streams have a hard-coded 24 Mbps bitrate. Since it </p>
</blockquote>
<p>is only a maximum, a lot of use cases are expected to be covered by that value, but customers with more specific needs are invited to get in touch with the GenAVB team to discuss possible solutions. This constraint will likely be removed in a future release.</p>
<h4><a class="anchor" id="autotoc_md17"></a>
CVF/H264</h4>
<p>the H264 stream has different packetization modes (Single Nal Unit, Fragmentation unit FU, STAP and MTAP) defined in RFC6184. The first constraint is that the header size for different modes is not the same and the NALU sizes is not fixed. That's why a parsing process is needed to prepare the packets with proper header regions before sending them to the stack.</p>
<p>A special function is dedicated for that : ::genavb_stream_h264_send Constraints for this function are:</p><ul>
<li>Data buffer should only contain a partial NALU (the beginning, a middle section or just the end) but the order of the byte stream must be respected.</li>
<li>The start of an NALU must always be at the start of the data buffer.</li>
<li>The last bytes of the NALU should be sent with an <a class="el" href="group__stream.html#ga5a0a46f6e4ddfa6236496dae45c98198" title="End of frame event.">AVTP_FRAME_END</a> event</li>
</ul>
<p>The AVB stream reservation will specify the maximum single nal unit size (equal to max AVTP payload size). Thus, NAL units bigger than the max AVTP payload size are sent as fragmentation units, otherwise it will be sent as a single packet. The event.ts field is used to pass, presentation timestamps that will be set to the h264_timestamp field of the AVTP H264 packet.</p>
<p>The following events should be used for described use cases:</p>
<ul>
<li><a class="el" href="group__stream.html#ga31ffedf58931d498048116f43ba42cea" title="Synchronization event.">AVTP_SYNC</a> events with valid presentation timestamps should be added with the beginning of every NALU to be passed later as h264_timestamp</li>
<li><a class="el" href="group__stream.html#ga5a0a46f6e4ddfa6236496dae45c98198" title="End of frame event.">AVTP_FRAME_END</a> event should be added to mark the end of a NALU. The associated data should be sent immediately.</li>
</ul>
<blockquote class="doxtable">
<p>Note: because of current GenAVB API limitations, an application cannot set the rate to use with a given stream, and as a result all H264 streams have a hard-coded 24 Mbps bitrate. Since it </p>
</blockquote>
<p>is only a maximum, a lot of use cases are expected to be covered by that value.</p>
<h3><a class="anchor" id="autotoc_md18"></a>
Control</h3>
<p>AVTP Control streams are relying on a Datagram mode by creating the stream using the <a class="el" href="group__stream.html#gga3f41b80b144c62352d1b276e9efa99b8a199c3a08feba937f632cb892c89566b5" title="Create stream in DATAGRAM mode.">AVTP_DGRAM</a> flag. In this mode the framing task is under the application responsability, with the AVB stack simply adding/removing AVTP and Ethernet headers to packets coming from/going to the application. The flag <a class="el" href="group__stream.html#ggae169475c394476b5cfc78a81a8fbc8f9ad49344af8b4c68682fc51aa45d94eaf8" title="Enable custom tspec definition.">GENAVB_STREAM_FLAGS_CUSTOM_TSPEC</a> shall be set in the stream's parameters flag meaning that the application defines the stream's properties which are defined by IEEE-1722 stream traffic specification (TSpec): payload size of the packets and number of packets per class interval.</p>
<h4><a class="anchor" id="autotoc_md19"></a>
ACF/NTSCF</h4>
<p>Asynchronous format which does not require any presentation timestamp event to be filled. Any timestamp event received by the stack for this mode is silently ignored.</p>
<h4><a class="anchor" id="autotoc_md20"></a>
ACF/TSCF</h4>
<p>Synchronous format requiring a presentation timestamp event for each packet. Any call to the stream send API without a timestamp will be treated as an error. </p>
</div></div><!-- contents -->
</div><!-- PageDoc -->
</div><!-- doc-content -->
<!-- HTML footer for doxygen 1.8.5-->
<!-- start footer part -->
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
  <ul class="foot">
    <li class="footer"> &copy; 2017-2020 NXP
    </li>
  </ul>
</div>
</body>
</html>
